Reconciliation for enabling accelerated access to contribution funded accounts

ABSTRACT

Disclosed herein are system, method, and computer program product embodiments for reconciliation needed to enable access to accelerated contribution funded accounts (CFAs). An embodiment operates by configuring a management database to store a linked CFA associated with a CFA and a CFA on demand (CFAOD). A contribution processing system of a provider may receive a contributions file from an employer. The contribution processing system may delay contribution reconciliation of the linked CFA until a contribution amount is received. During contribution reconciliation, the contribution processing system may resolve the CFAOD using the received contribution amount such that the amount borrowed is minimized before funding the CFA with a remaining contribution amount. Upon resolution of the CFAOD, the contribution processing system may concurrently send information to a bank server and a card server to reconcile the respective bank and card accounts with the linked CFA at the provider.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.15/651,645, filed Jul. 17, 2017, entitled “Reconciliation For EnablingAccelerated Access to Contribution Funded Accounts” to Roberts et al.,which was a continuation of PCT Application No. PCT/US2016/021752, filedMar. 10, 2016, which in turn claims the benefit of U.S. ProvisionalPatent Application No. 62/131,057, filed Mar. 10, 2015, all of which areincorporated by reference herein in their entireties.

BACKGROUND

Contribution funded accounts (CFAs) may be tax-advantaged financialaccounts that may be set up through, for example, a cafeteria planprovided by an employer. A cafeteria plan is a reimbursement plan thatallows employees to contribute, pre-tax, some of their total income to adesignated account. The selected plan may allow an employee tocontribute a portion of his pre-tax earnings at the end of each payperiod to fund the CFA. The funds within the CFA may be used to pay forqualified expenses as established in the cafeteria plan.

The plan is typically a year-long plan that may be updated and/orannually renewed. As the plan year progresses and contributions fromeach pay period are added to the CFA, an employee may gain access to anincreasing amount of tax-advantaged funds to pay for qualified expenses.However, an employee typically only has access to funds currently storedin the CFA. Therefore, especially towards the beginning of the plan yearwhen funds in the CFA are just starting to accumulate, an employee maynot have adequate funds in the CFA to pay for large qualified expenses.

To enable accelerated access to CFAs, a plan manager may provide alinked CFA that links a CFA with a CFA On Demand (CFAOD). The CFAOD maycontain funds that reflect future contributions that have yet to be usedto fund the CFA. By enabling an employee accelerated access to futurecontributions, the employee may more likely be able to pay for largequalified expenses starting from the first day of the plan year.

In order to manage a CFA, a plan manager may typically need to manageand reconcile CFAs stored in databases across multiple entitiesincluding the employer, bank, and card vendor, plan manager, sponsor,and distributor. With the introduction of the new account type, theCFAOD, new reconciliation processes may be required to manage the CFAsin the databases of the multiple entities. These new reconciliationprocesses may further introduce synchronization latencies across themultiple entities that may need to be minimized to enable an employeefull and uninterrupted access to accelerated CFAs.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings are incorporated herein and form a part of thespecification.

FIG. 1 is an example block diagram illustrating the multiple systems ofrespective entities involved in providing and maintaining acceleratedaccess to contribution funded accounts, according to an exampleembodiment.

FIG. 2 is an example block diagram illustrating the components within anemployee user interface portal for providing an employee access to hiscontribution funded account, according to an example embodiment.

FIG. 3 is an example block diagram illustrating the components within anemployer accounts system for interacting with an accounts managementsystem for tracking employees' linked contribution funded accounts,according to an example embodiment.

FIG. 4 is an example block diagram illustrating the components within anaccounts management system to reconcile contribution funded accountsstored across multiple systems to enable accelerated access to thecontribution funded accounts, according to an example embodiment.

FIG. 5 is an example block diagram illustrating the components within abank accounts system to manage contribution funded accounts at a bank,according to an example embodiment.

FIG. 6 is an example block diagram illustrating the components within acard accounts system to manage contribution funded accounts at a cardvendor, according to an example embodiment.

FIG. 7 is a sequence diagram illustrating a process for reconcilingcontribution funded accounts across multiple systems in order to enrollan employee into an accelerated contribution funded account plan,according to an example embodiment.

FIG. 8 is a sequence diagram illustrating a process for reconcilingaccelerated contribution funded accounts across multiple systems inorder to process a contribution from an employer, according to anexample embodiment.

FIG. 9 is a sequence diagram illustrating a process for reconcilingaccelerated contribution funded accounts across multiple systems inorder to apply a claims request from an employee, according to anexample embodiment.

FIG. 10 is a sequence diagram illustrating a process for reconcilingaccelerated contribution funded accounts across multiple systems inorder to apply a claims request from a card vendor, according to anexample embodiment.

FIG. 11 is a sequence diagram illustrating a process for reconcilingaccelerated contribution funded accounts between an employer and a planmanager when an employee leaves the employer, according to an exampleembodiment.

FIG. 12 is a flowchart illustrating steps for reconciling acceleratedcontribution funded accounts across multiple systems in order to processa contribution from an employer, according to an example embodiment.

FIG. 13 is a flowchart illustrating steps for reconciling acceleratedcontribution funded accounts across multiple systems in order to processa claims request, according to an example embodiment.

FIG. 14 is a flowchart illustrating steps for reconciling acceleratedcontribution funded accounts at a card provider in order to process apayment transaction, according to an example embodiment.

FIG. 15 is an example computer system useful for implementing variousembodiments.

In the drawings, like reference numbers generally indicate identical orsimilar elements. Additionally, generally, the left-most digit(s) of areference number identifies the drawing in which the reference numberfirst appears.

DETAILED DESCRIPTION

Provided herein are system, method and/or computer program productembodiments, and/or combinations and sub-combinations thereof, forefficient and latency-minimized reconciliation of accelerated accessenabling contribution funded accounts (CFAs) stored in databases acrossmultiple entities including the employer, the bank, and the card vendor.In an embodiment, reconciliation processes may be adjusted to process anemployee's enrollment into a CFA plan, an employee's contribution, anemployee's claims, and an employee's termination of the CFA plan and/orfrom his employer.

A CFA may be any tax-advantaged financial account that is set up by anemployee through, for example, a cafeteria plan of an employer. Whilethe present application will use a cafeteria plan as an example, one ofskill in the art would recognize that other types of employee benefitplans may alternatively or additionally be provided by the employer. Thecafeteria plan selected by the employee may allow an employee tocontribute a portion of his pre-tax earnings at the end of each payperiod to fund the CFA. The funds within the CFA may be used to pay forqualified expenses as established in the cafeteria plan. For example,CFAs may include flexible spending accounts (FSAs), such as health FSAs,dependent care FSAs, limited expense FSAs, adoption related FSAs, amongother types of FSAs. A CFA may additionally include non-FSAs such ashealth savings accounts (HSAs) and other contributions basedtax-advantaged accounts.

To enable accelerated access a plan manager may provide a linked CFAthat links various sub-accounts. For example, a CFA may be linked to aCFA On Demand (CFAOD). In an embodiment, the CFA may itself be comprisedof two sub-accounts: an employer funded CFA and/or an employee fundedCFA. In an embodiment, the CFAOD may be initialized with a sum ofcontributions to be made in a plan year, while the CFA may contain azeroed balance. In an embodiment, the CFA may contain a preexistingbalance from the previous plan year. As contribution amounts from eachpay period are added to the CFA, the same contribution amounts arededucted from the CFAOD to maintain total available funds within thelinked CFA including the CFA and the CFAOD. Therefore, a contributionfrom a pay period effectively transfers the specified contributionamount from the CFAOD to the CFA. By enabling an employee acceleratedaccess to future contributions stored within the CFAOD, the employee maymore likely be able to pay for larger qualified expenses starting fromthe first day of the plan year.

FIG. 1 illustrates a linked CFA system 100 for providing and maintainingaccelerated access to CFAs across multiple entities including anemployer, an employee, a bank, a card vendor, and a plan manager,according to an embodiment. Linked CFA system 100 includes network 102,employee computer 104 operated by the employee, employer accounts system106 of the employer, plan management system 108 of the plan manager,bank accounts system 110 of the bank, and card accounts system 112 ofthe card vendor. Each of the systems and/or computer may be implementedusing one or more processors. Although the systems are depicted asremote systems connected via network 102 in CFA system 100, one or moresystems may be operated by and/or maintained by one entity. For example,bank accounts system 110 and card accounts system 112 may be part of asingle system operated by one entity.

Network 102 may enable plan management system 108 to communicate withand reconcile CFAs stored at the multiple systems: employer accountssystem 106, bank accounts system 110, and card accounts system 112. Inan embodiment, employee computer 104 may communicate with and view CFAinformation stored on any of the depicted systems. In an embodiment,employer computer 104 may access a portal provided by plan managementsystem 108 that acts as an interface for viewing CFA information storedon any of the depicted systems. Network 102 may be an enterprise widearea network (WAN) utilizing Ethernet communications, although otherwired and/or wireless communication techniques, protocols andtechnologies may be used.

FIG. 2 illustrates exemplary components within an employee userinterface (UI) portal 202 that employee computer 104 may access vianetwork 102, according to an example embodiment. In an embodiment,employee user UI portal 202 is accessible to the employee via a mobiledevice operated by the employee. Employee UI portal 202 may enable theemployee to access his linked CFA managed by plan management system 108.In the exemplary embodiment of FIG. 2 , employee UI portal 202 mayinclude CFA update component 204, claims generation component 206, andCFA viewer 208. In an embodiment, each of CFA update component 204,claims generation component 206, and CFA viewer 208 may be accessiblevia respective panes on a homepage of employee UI portal 202 and/or viaa menu toolbar of employee UI portal 202.

CFA update component 204 may be configured to enable an employeeoperating employee computer 104 to update information related tomaintaining his CFAs. In an embodiment, CFA update component 204 may beoperated by the employee to elect a particular cafeteria plan to set upa CFA for a plan year. The cafeteria plan may include a traditional CFAas well as a linked CFA comprising a CFA linked to a CFAOD. Employee UIportal 202 may send the election results to employer account system 106to set up, for example, the linked CFA. In an embodiment, depending onrestrictions established by an employer and/or the cafeteria plan, theemployee may make adjustments to the cafeteria plan throughout the planyear via CFA update component 204. Other capabilities CFA updatecomponent 204 may provide include allowing the employee to invest fundsin his linked CFA, to manually contribute and/or transfer funds to thelinked CFA, and/or to terminate his cafeteria plan.

Claims generation component 206 may be configured to enable an employeeoperating employee computer 104 to enter claims to be paid and/orreimbursed using funds within the linked CFA. The employee may manuallyenter a claim having service information and a claim amount. The serviceinformation may include, for example, a service type, a date of theservice, and an entity providing the service. The entered claims mayadditionally be required to include a proof of service such as a receiptused to verify the service and the claim amount. In an embodiment,claims generation component 206 may be configured to provide apre-generated claims request template according to the CFA plan. For alinked CFA associated with a health related plan, claims generationcomponent 206 may, for example, pre-generate templates for variousservices and items covered by the health plan.

Linked CFA viewer 208 may be configured to enable an employee operatingemployee computer 104 to view current statuses and balances ofsub-accounts within the linked CFA. In an embodiment, the employee maybe able to track transactions and respective statuses for eachsub-account. Statuses may include those known to one skilled in the art,such as SETTLED if a transaction has been processed or PENDING if thetransaction is undergoing processing. In an embodiment the SETTLEDstatus may further include or instead be a PAID status to indicate atransaction was successfully processed or INELIGIBLE if the transactioncould not be processed i.e. denied. The PENDING status may be associatedwith a transaction under review or in the process of being reimbursed.

In an embodiment, linked CFA viewer 208 may enable the employee to viewan overall balance of the linked CFA, but also balances of thesub-accounts such as the CFAOD. Linked CFA viewer 208 may also allow theemployee to see transactions and associated claims made against each ofthe sub-accounts. For example, if a contribution amount is made at theend of a pay period, a transaction crediting a CFA of a linked CFA bythe contribution amount may be displayed, as well as a transactiondebiting a CFAOD of the linked CFA by the same contribution amount.Therefore, the total fund within the linked CFA remains unchanged beforeand after the contribution. In another example, if a claim is madeagainst the linked CFA, a transaction debiting the CFA may be displayed.If funds from the CFA were insufficient, a transaction debiting theCFAOD by an amount needed to completely service the claim may also bedisplayed.

FIG. 3 illustrates employer accounts system 300 maintained by anemployer for interacting with plan management system 400 to track itsemployees' linked CFAs, according to an exemplary embodiment of employeraccounts system 106. Employer accounts system 300 may include employerserver 302 and employer database 301. Though depicted as a singleserver, employer server 302 may be representative of a plurality ofservers, each of which may be implemented by one or more processors.Likewise, employer database 301 may be representative of a plurality ofdatabases coupled to a plurality of employer servers.

Employer database 301 may be configured to store employee information,employer plan offerings, and employee selections of plan offerings.Employee information may include various information such as censusinformation, salaries, and employment statuses. Employer plan offeringsmay include, for example, a traditional CFA, such as an HSA, or a linkedCFA containing a CFA linked to a CFAOD. Employee selections may includeinformation associated with an employee's election of an employer planoffering for a plan year, employees' elected contributions to fund CFAs,as well as whether CFA funds are being invested. In an embodiment,employer database 301 may also store account information of CFAs(including linked CFAs) and associated transaction logs. Transactionlogs may, for example, track contributions and claims made on the linkedCFAs.

Employer server 302 may instantiate employer user interface (UI) portal304. Portal 304 may include status update processing component 306,contribution processing component 308, and invoice reporting component310. One or more of these depicted components may be implemented asprocessing systems comprising one or more sub-components. Thesesub-components may include an interface for communicating within and/oracross systems and a distribution component for sending information toother components and/or across systems. For example, contributionprocessing component 308 may be implemented as a contribution processingsystem including an interface for receiving information and adistribution component for sending information.

Generally, employer UI portal 304 may be configured to allow anemployer, particularly benefits administrators of the employer, tomanually adjust and/or input employee statuses, employer offerings, andcontribution proportions of employee income and associated amountsthrough the use of various components as will be discussed. Theadjustments may be performed by the various components and sent to planmanagement system 108 to update linked CFAs managed at the planmanagement system 108. In an embodiment, employer UI portal 304 may beconfigured to allow an employer to view details of employee CFA/CFAODssuch as CFA/CFAOD statuses, CFA/CFAOD balances, and transactions relatedto contributions to CFAs.

In an embodiment, employer UI portal 304 may only adjust and viewemployer or employee contributions as specified by an employer benefitsplan. Other contributions, such as contributions that are outside of theemployer benefits plan and made by an employee through employee UIportal 202 may not be viewable. In addition to viewing details, employerUI portal 304 may be configured to provide analytics and reportgeneration capabilities.

Status update processing component 306 within employer UI portal 304 maybe configured to enable an employer to input information related to anemployee's selected employer plan offering. For example, status updateprocessing component 306 may enable an employer to input information toadjust an employee's enrollment within a linked CFA near the end of eachplan year. Accordingly, status update processing component 306 may sendupdate information to plan management system 108 that manages andupdates the linked CFAs. In an embodiment, information for updating thelinked CFA may include information indicating enrollment of a new orexisting employee into a linked CFA in accordance with an employeeelected employer benefits plan. For enrollment, status update processingcomponent 306 may additionally be configured to send census andeligibility information of the employee, which may be retrieved fromemployer database 301.

To set up traditional CFAs, update information may include employeecensus/eligibility information and information about one or both ofemployee and employer funded account types tied to a specific plan year.The plan management system 108 may then set up a CFA using thedesignated account(s). But to set up a linked CFA enabling acceleratedaccess to CFA funds, update information may additionally includeinformation about a third account type, the CFAOD. The CFAOD, which maybe linked to a traditional CFA, provides the accelerated funds to theemployee. In an embodiment, status update processing component 306 maysend a message associating an employee with his elected employer benefitplan. In an embodiment, various employee or employer selectedrestrictions or options may also be included in the update information.For example, employee restrictions/options may include a proportion ofhis income (or the actual contribution amount) to fund the linked CFA atthe end of every pay period. An employer may specify a maximum totalcontribution amount for an employee in a plan year for one or more ofthe sub-account making up the linked CFA. The employer may also cap amaximum amount of an employee's future pledged contributions to be madeavailable to the employee for advancement. At the time of contribution,any eligible contribution amount will then be effectively decreased fromthe CFAOD and added to the CFA. Upon receiving the set-upinformation/message, plan management system 108 may set up a linked CFAenabling an employee immediate and accelerated access to futurecontributions to use for an expense immediately before the futurecontribution is applied.

In an example scenario, an employee may elect to contribute $100 for 12months totaling $1200 available for advancement on the first day of theplan year. But, the employer may limit the maximum amount an employeemay contribute to the linked CFA in the plan year to $1000. The capamount may depend on a combination of employee information, employerbenefit plan type, and government regulations. The employer may alsolimit, for example, the total future contributions to be made availablefor advancement to $800. In this scenario, the employee may only gainaccelerated access to $800 of his linked CFA on the first day of theplan year, as opposed to the $1000 designated by the total contributionlimit.

Contribution processing component 308 may be configured to process andmanage an employee's contributions to his one or more linked CFAs perpay period. First, based on employee enrollment and update informationstored in employer database 301, contribution processing component 308may generate a contributions file specifying a proportion of everyemployee's income (or alternatively an actual contribution amount) for apay period. In an embodiment, the contribution file may only containcontribution information of select employees, e.g. employees enrolled inone or more linked CFAs or CFAs. Accordingly, the generatedcontributions file may be sent to plan management system 400 for eachpay period.

Contribution processing component 308 may then receive a contributionsfunding request (CFR) from plan management system 400 specifying aproportion of the contribution amounts specified in the sentcontributions file that must be transmitted from employer accountssystem 300 to plan management system 400. The actual contributionamounts to be transmitted may not match the amounts in the contributionsfile for any number of reasons. For example, plan management system 400may determine, for an employee, that he does not exist in the planmanagement system 400, he has not enrolled in a linked CFA, his linkedCFA account has not been enabled or is terminated, or his designatedcontribution amount exceeds a specified maximum amount. In these cases,the employee's contribution amount will not be included in the CFR.Invoice reporting component 310 may be configured to periodicallyreceive and report invoices generated by plan management system 108. Inan embodiment, invoice reporting component 310 may receive an employerweekly funding request (EWFR) detailing payback records and billingrecords for employees enrolled in at least one linked CFA or traditionalCFA. In an embodiment, the employer funding request may be sentbi-weekly or quarterly, etc., and not necessarily on a weekly basis.

A billing record for an associated employee may indicate that a portionof the employee's funds in a CFAOD has been withdrawn (or borrowed) toservice a claim because the funds within the employee's CFA was notsufficient. In this scenario, the employer may need to reimburse theprovider the withdrawn portion. A payback record of an associatedemployee may indicate that a portion of an employee's previouscontribution(s) was used to repay funds previously withdrawn from theCFAOD to service a claim. In summary, an employer may be billed for anyamount borrowed from an employee's CFAOD. Accordingly, the employer mayneed to be paid back any amount used to repay an amount previouslyborrowed from the CFAOD. Relatedly, in an embodiment, only claims thatrequire funding from the CFAOD may be invoiced. The invoice may then bereceived and reported by invoice reporting component 310.

In an embodiment, the EWFR may also include contribution records andclaims records for the employees on a weekly basis. These records may beassociated with payback and billing records, respectively. In anembodiment, payback records and billing records may be represented andtransmitted in a transactional format.

FIG. 4 illustrates plan management system 400 maintained by a planmanager for managing linked CFAs of one or more employers andcorresponding employees across multiple entities, according to anexemplary embodiment of plan management system 108. Plan managementsystem 400 may include interface 405, management server 402, andmanagement database 418. Though depicted as a single server, managementserver 402 may be representative of a plurality of servers, each ofwhich may be implemented by one or more processors. Likewise, managementdatabase 418 may be representative of a plurality of databases coupledto a plurality of management servers. Management database 418 may beimplemented on one or more storage devices.

Interface 405 may be configured to enable plan management system 400,specifically management server 402, to communicate with one or more ofthe systems depicted in FIG. 1 . Though depicted as a separatecomponent, interface 405 may be implemented within management server402, according to an exemplary embodiment.

Management database 418 may be configured to store employer informationand employee information via one or more database tables or managementTXN log(s) 420. Employer information may include employer benefit planofferings and related information or restrictions as described in FIG. 2. Employee information may include various information such as censusinformation, salaries, employment status, associated employer, electedemployer plan, contribution amounts, linked CFA account information, andother information related to customizing a linked CFA. In an embodiment,employee information may also include investment information such as aproportion of funds within a linked CFA that are currently allocated forinvesting. Investment information may be received by investment entitiesvia file and web services.

The linked CFA information may be stored in linked CFA table 426associating an employee with a linked CFA. Based on sub-accountsdesignated by an elected employer plan, linked CFA table may be linkedto CFA table 428, storing traditional CFA information, and CFAOD table434, storing CFAOD information. Other types of sub-accounts and CFAs maybe linked to a linked CFA account in linked CFA table 426. To maintainan employee's CFA, a CFA record within CFA table 428 may include astatus 430 field and a balance 432 field. To maintain an employee'sCFAOD, a CFAOD record within CFAOD table 434 may include a status 436field, a balance 438, and an amount borrowed 440 field.

Status 430 and 436 may reflect a status of an employee's CFA and CFAOD,respectively. For example, status 430 may indicate a CFA is ACTIVE,CLOSED, PENDING, or SUSPENDED. These statuses may correspond to a CFAset up at a bank. Status 436 may indicate a CFAOD is ACTIVE, FROZEN,IN-COLLECTION, or CLOSED. These statuses may be unique due to theproperties of a CFAOD. A FROZEN state may indicate that funds of a CFAODmay not be accessible and transferred to a CFA to enable an employeeaccelerated access to future contributions. The FROZEN status may be setif, for example, an employee elects to invest funds within his linkedCFA. The IN-COLLECTION status may be set when an employee's linked CFAaccount is terminate if, for example, the employee leaves the employerbefore the end of the plan year.

Balance 432 and 438 may reflect an account balance of an employee's CFAand CFAOD, respectively. As explained, balance 432 represents real fundscorresponding to funds stored in a CFA at the bank, and balance 438represents future contributions of the plan year less any amountborrowed 440 to service a claim. Amount borrowed 440 may total a currentamount of CFAOD funds borrowed to service one or more claims less anyamount repaid via an employee's periodic contributions.

Management TXN log 420 may store transactions received from any systemof FIG. 1 . In an embodiment, management TXN log 420 primarily storestransaction records related to employee contributions and claims.Management TXN log 420 may be linked to card TXN log 422 and bank TXNlog 424. Card TXN log 422 may contain card transactions generated whileprocessing a transaction stored in management TXN log 420. Bank TXN log424 may contain bank transactions generated while processing atransaction stored in management TXN log 420. These card and banktransactions may be generated when, for example, processingcontributions and claims. In an embodiment, records within card TXN log422 and bank TXN log 424 may be stored within one transaction log, suchas management TXN log 420.

Management server 402 may be configured to include management UI portal404, status processing component 406, contribution processing component408, claims processing component 410, invoice processing component 412,and TXN manager 414. One or more of the depicted components may beimplemented as processing systems comprising one or more sub-components.These sub-components may include an interface for communicating withinand/or across systems and a distribution component for sendinginformation to other components and/or across systems.

Management UI portal 404 may be configured to allow a provider and itsemployees the capability to adjust and maintain employee's statuses,employers' offerings, and information related to an employee's linkedCFA. Adjustments made within management UI portal 404 may be propagatedto employer accounts system 106, bank accounts system 110, and/or cardaccounts system 112. In an embodiment, management UI portal 404 may beconfigured to allow a provider to view details of employee CFAs(including linked CFAs) such as CFA statuses, CFA balances, transactionsof claims filed per employee, and transactions related to contributionsto CFAs for each employer serviced by plan management system 108. Inaddition to viewing details, management UI portal 404 may be configuredto provide analytics and report generation capabilities.

Status update processing component 406 may be configured to communicatewith status update processing component 306 in employer accounts system300 in order reconcile updates to an employee's linked CFA across themultiple systems of FIG. 1 including plan management system 108, bankaccounts system 110, and card accounts system 112. For example, statusupdate processing component 406 may receive a request from employeraccounts system 108 for updating an employee's linked CFA.

Accordingly, status update processing component 406 may update recordsstored in management database 418, such as linked CFA table 426. Then,status update processing component 406 may initiate a reconciliationprocess and send update information to bank accounts system 110 and cardaccounts system 112. In an embodiment, updating the linked CFA mayinclude enrolling a new or existing employee into a linked CFA inaccordance with an employee elected employer benefit plan.

Contribution processing component 408 may be configured to communicatewith contribution processing component 308 in employer accounts system300 in order to reconcile an employee's contributions across themultiple systems of FIG. 1 including plan management system 108, bankaccounts system 110, and card accounts system 112. Upon receiving acontribution file from employer accounts system 106, contributionprocessing component 308 may resolve the pledged contributions togenerate a CFR as described in FIG. 3 . Then, contribution processingcomponent 408 may then reconcile the linked CFA stored in linked CFAtable 426 and associated tables CFA table 428 and CFAOD table 434 beforegenerating and sending transactions to bank accounts system 110 and cardaccounts system 112 to reconcile one or more sub-accounts of linked CFAstored external to plan management system 400.

In an embodiment, contribution processing component 408 may beconfigured to accept a direct contribution from an employee via CFAupdate component 204 of employee UI portal 202. In an embodiment,because the direct contribution is not automatically deducted from theemployee's paycheck at the end of a pay period, the contribution amountmay be added to the CFA of the linked CFA and no updates to the CFAODmay be made.

Claims processing component 410 may be configured to communicate withclaims generation component 206 in employee UI portal 202 in order toreconcile an employee's submitted claims across the multiple systems ofFIG. 1 including plan management system 108, bank accounts system 110,and card accounts system 112. Upon receiving a claims request fromemployee UI portal 202, claims processing component 408 may resolve theclaims request and reconcile the linked CFA, stored in linked CFA table426 and associated tables CFA table 428 and CFAOD table 434, beforegenerating and sending transactions to bank accounts system 110 and cardaccounts system 112 to reconcile one or more sub-accounts of linked CFAstored external to plan management system 400. In an embodiment, claimsprocessing component may also or instead be configured to communicatewith a benefits plan provider, which submits an employee's claims.

In an embodiment, claims processing component 410 may be similarlyconfigured to communicate with card accounts system 112 in order toreconcile an employee's claim(s) request made on a card across themultiple systems of FIG. 1 including plan management system 108, bankaccounts system 110, and card accounts system 112. A claims request maybe generated within card accounts system 112 when a user swipes a cardassociated with funds of a linked CFA to pay for services. Uponreceiving a claims request, likely in the form of payment transactions,from card accounts system 112, claims processing component 408 mayresolve the claims request and reconcile the linked CFA stored in linkedCFA table 426 and associated tables CFA table 428 and CFAOD table 434before generating and sending transactions to bank accounts system 110to reconcile one or more sub-accounts of linked CFA stored external toplan management system 400. In an embodiment, no transactions may needto be sent to card accounts system 112 because the claims request wasoriginated on card accounts system 112.

Invoice processing component 412 may be configured to periodicallycommunicate with invoice reporting component 310 in employer accountssystem 300 in order to keep balances maintained within employer accountssystem 106 and plan management system 107 in sync. For example, duringcontribution processing, invoice processing component 412 may generateand send a CFR, as described in FIG. 3 , to employer accounts system106. In another example, during claims processing, invoice processingcomponent 412 may generate and send an EWFR detailing payback recordsand billing records for an employer's employees, as described in FIG. 3. In summary, invoices may be generated and sent by invoice processingcomponent 412 such that expenses paid by borrowing from CFAODs, whichrepresent future not-yet-received contributions, are billed to theemployer and any portion of the borrowed funds of CFAODs repaid byemployees are refunded or paid back to the employer.

In an embodiment, when an employee leaves the employer, invoiceprocessing component 412 may be configured to manage and trackcollections to be retrieved from the employee to pay funds borrowed fromCFAODs. In an embodiment where actual collections take place between theemployee and his employer, invoice processing component 412 may onlytrack the collection transaction information received from employeraccounts system 106 and periodically send reports detailing status ofcollections to employer accounts system 106.

TXN manager 414 may be configured to manage transactions received fromany of the systems in FIG. 1 and generate associated transactions whileprocessing employee status updates, employee contributions, and employeeclaims via one of the components depicted in management server 402.Received transactions may be stored in management TXN log 420 andgenerated transactions may be stored in card TXN log 422 and bank TXNlog 424. As part of reconciling a linked CFA across the multiple systemsof FIG. 1 , TXN manager 414 may send the generated bank and cardtransactions to TXN manager 604 in bank accounts system 600 and TXNmanager 504 in card accounts system 500, respectively.

FIG. 5 illustrates bank accounts system 500 maintained by a bank formanaging CFAs of one or more employers and corresponding employees,according to an exemplary embodiment of bank accounts system 110. Bankaccounts system 500 may include bank server 502 and bank database 508.Though depicted as a single server, bank server 502 may berepresentative of a plurality of servers, each of which may beimplemented by one or more processors. Likewise, bank database 508 maybe representative of a plurality of databases coupled to a plurality ofbank servers. Additionally, one or more of the depicted components maybe implemented as processing systems comprising one or moresub-components. These sub-components may include an interface forcommunicating within and/or across systems and a distribution componentfor sending information to other components and/or across systems.

Bank database 508 may be configured to store employee information viaone or more database tables and bank TXN logs. Employee information mayinclude an employee's personal information and information related to aCFA stored in CFA table 510. Similar to a CFA stored in CFA table 428 ata management database 418, a CFA account stored in CFA table 510 isassociated with status 512 and balance 514 corresponding to status 430and balance 432, respectively. Whereas the CFA stored in CFA table 510may be associated with a real banking account, the CFA stored in CFAtable 428 in a management database 418 may be a proxy for the realbanking account. Therefore, in an embodiment, bank database 508 maystore traditional CFAs, but not a CFAOD because the funds within theCFAOD represent contributions yet-to-be received.

Bank database 508 may also be configured to store and maintaintransaction logs within bank TXN log 516. These transactions may bereceived, for example, from TXN manager 414 within plan managementsystem 400. The received transactions may then be applied to variousfields of a CFA account in CFA table 510.

Bank server 502 may be configured to include TXN manager 504 and statusupdate processing component 506. Status update processing component 506may be configured to communicate with status update processing component406 in plan management system 400 in order to reconcile an employee'sbank CFA with a proxy CFA stored at the plan management system 400. Forexample, status update processing component 506 may receive a requestfrom plan management system 400 to update an employee's bank CFA.Accordingly, status update processing component 506 may update recordsstored in bank database 508, such as changing status 512 to CLOSED orupdating an amount of balance 514. Update results may be sent to planmanagement system 400. In an embodiment, updating the bank CFA mayinclude enrolling a new or existing employee into a new bank CFA inaccordance with the received request. In this exemplary embodiment,status update processing component 506 may generate a new bank CFAidentifier and return the CFA ID along with enrollment results to planmanagement system 400.

TXN manager 504 may be configured to process transactions received fromone or more of the systems or computers depicted in FIG. 1 as would beunderstood by one skilled in the art. In an embodiment, TXN manager 504may be configured to receive transactions generated by plan managementsystem 400 for contribution and claim reconciliation as described inFIG. 3 . Upon resolving the received transactions and applyingassociated updates to CFAs in CFA table 510, TXN manager 504 may sendresults of transaction processing to plan management system 400.

FIG. 6 illustrates card accounts system 600 maintained by a card vendorfor managing CFAs of employees from one or more employers, according toan exemplary embodiment of card accounts system 112. Card accountssystem 600 may include card server 602 and card database 608. Thoughdepicted as a single server, card server 602 may be representative of aplurality of servers, each of which may be implemented by one or moreprocessors. Likewise, card database 608 may be representative of aplurality of databases coupled to a plurality of card servers.Additionally, one or more of the depicted components may be implementedas processing systems comprising one or more sub-components. Thesesub-components may include an interface for communicating within and/oracross systems and a distribution component for sending information toother components and/or across systems.

Card database 508 may be configured to store card TXN logs and employeeinformation via one or more database tables. Employee information mayinclude an employee's personal information and information related tothe employee's one or more linked CFAs stored in linked CFA table 616.In this exemplary embodiment, each linked CFA specified by an employerbenefit plan may be stored in a separate linked CFA table 616. But, inan embodiment, disparate linked CFAs may be stored and maintained withinone or more common tables. Linked CFAs may each include one or moresub-accounts. For example, linked CFA table 616A may contain a linkedCFA comprising a first sub-account CFA stored in CFA table 618A and asecond sub-account CFAOD stored in CFAOD table 624. In contrast, linkedCFA table 616A may contain only a CFA within CFA table 618B withoutcontaining a corresponding nominal CFAOD. The statuses and balances ofCFAs and CFAODs may correspond to those described for CFAs and CFAODsstored within management database 418 in FIG. 4 . The main difference isthat the funds within the linked CFAs and related sub-accounts arerepresentative of funds on a card that a user may use to pay forqualified services when the card is swiped. Each linked CFA andassociated sub-accounts may be associated with qualified service typesaccording to respective employer benefit plans.

User multi-purse (MP) table 610 may be configured to store MP tables 612needed to service an employee's card account. In an embodiment, anemployee's card account may be associated with linked CFAs stored inlinked CFA table 616A and linked CFA table 616B. Not only do therestrictions, qualified service types, and other details of linked CFAsdiffer based on the employer benefit plan, but also information andrestrictions of sub-accounts within the linked CFAs may differ as wellbased on the employer benefit plan. To efficiently manage how andwhether funds within a card account can be used, MP tables 612 may beconfigured to store a set of sub-accounts, an order to process accountswithin the set, and qualified service types of one or more sub-accountswithin the set. An MP table 612 may correspond to one or more linked CFAaccounts of an employee. In an embodiment, an MP table 612 may onlycorrespond to one linked CFA account of an employee.

For example, MP table 612A specifies the following sub-accounts enabledon the employee's card: CFA 618A, CFAOD 624, CFA 618B. The labelsfollowing the sub-accounts represent accounts stored in correspondingsub-account tables. MP table 612A also specifies a priority from high(1) to low (3) to use funds of the sub-accounts to pay for cardtransactions. MP table 612A may also store qualified services forcorresponding sub-accounts based on employer benefit plan(s). Incontrast, MP table 612B may exclude the sub-account CFAOD 624 from itsset of stored sub-accounts. Additionally, CFA 618B may be assigned ahigher priority (1) than CFA 618A, assigned a priority of (2).

In an embodiment, an MP table 612 may be selected based on an MP indexreceived from plan management system 400. The MP index may be determinedat plan management system 400 based on one or more statuses of anemployee's corresponding one or more linked CFAs. For example, if anemployee's CFA funds are currently being invested, the received MP indexmay select MP table 612B, which effectively disables access toaccelerated funds provided by a CFAOD on the card. This option may beselected to reduce risk and simplify reconciliation of linked CFAsmaintained by plan management system 400.

Card server 602 may be configured to include TXN manager 604 and statusupdate processing component 606. Status update processing component 606may be configured to communicate with status update processing component406 in plan management system 400, in order to reconcile an employee'scard CFA with a proxy CFA stored at the plan management system 400. Forexample, status update processing component 606 may receive a requestfrom plan management system 400 to update an employee's card CFA.Accordingly, status update processing component 606 may update recordsstored in card database 608, such as changing status 620B to CLOSED orselecting MP table 612B to use during card transaction processing basedon a received MP index. Results of updates and any errors may be sent toplan management system 400. In an embodiment, updating the card CFA mayinclude enrolling a new or existing employee into a new card (linked)CFA in accordance with the received request. In this exemplaryembodiment, status update processing component 606 may receive a cardaccount number from plan management system 400 and generate a new cardaccount associated with one or more linked CFAs. Then, status updateprocessing component 606 may return enrollment results to planmanagement system 400. In an embodiment, when enrolling an employee intoa new card account, status update processing component 606 may generatea new card account number while generating a new card account andtransmit the new card account number upon successfully generating thenew card account.

TXN manager 604 may be configured to process transactions received fromone or more of the systems or computers depicted in FIG. 1 as would beunderstood by one skilled in the art. In an embodiment, TXN manager 604may be configured to receive transactions generated by plan managementsystem 400 for contribution and claim reconciliation as described inFIG. 3 . Upon resolving the received transactions and applyingassociated updates to CFAs and CFAODs stored in linked CFA tables 616,TXN manager 604 may send results of transaction processing to planmanagement system 400.

FIG. 7 illustrates an enrollment process 700 for reconciling CFAs acrossmultiple systems in order to enroll an employee into a linked CFAenabling accelerated access to funds in CFAs, according to an exampleembodiment. The multiple systems may include employer account system300, plan management system 400, bank accounts system 500, and cardaccounts system 600 as described in FIGS. 3-6 , respectively. Process700 may be performed by processing logic that may include hardware(e.g., circuitry, dedicated logic, programmable logic, microcode, etc.),software (e.g., instructions run on a processing device), or acombination thereof. In an embodiment, steps in FIG. 7 may not need tobe performed in the exact order shown, as one skilled in the arts wouldunderstand. In an embodiment, enrollment process 700 may be adjusted toenable updating a pre-existing linked CFA associated with the employee.

In step 702, status update processing component 306 within employeraccounts system 300 may send census information associated with anemployee to plan management system 400, as described in FIG. 3 . Step702 may be initiated when an employee is hired by an employer and/orwhen an employee decides to enroll into a new linked CFA according tohis elected employer benefit plan. Upon receiving the census informationat plan management system 400 via interface 405, status processingcomponent 406 within plan management system 400 may store the employeeand associated census information into management database 418. But, noCFA information may yet be associated with the stored employee record.

In step 704, status update processing component 306 may send enrollmentinformation related to an employee's enrollment into an elected employerbenefit plan. As described in FIG. 3 , the enrollment information mayinclude a type of linked CFA, a proportion of an employee's income to becontributed to the CFA for each pay period, the number of pay periods ina plan year, and a contribution amount from the employer to the CFA perpay period. The enrollment information may depend on the electedemployer benefit plan, the employer, and the plan manager. In anembodiment, steps 702 and 704 may be condensed into a single step whereboth census information and enrollment information of an employee may besent by employer accounts system 300 to plan management system 400. Inan embodiment where update information is to be sent instead ofenrollment information, step 702 may be omitted and status updateprocessing component 306 may send update information to plan managementsystem 400 in step 704.

In step 706, upon receiving the enrollment information at planmanagement system 400 via interface 405, status processing component 406may be configured to generate a linked CFA for the employee according tothe elected employer benefit plan. Depending on the elected employerbenefit plan, one or more of the following sub-accounts may be generatedand linked to the linked CFA: a CFA funded by the employer, a CFA fundedby the employee, and a CFAOD. If an employee did not elect into anaccelerated CFA, then the CFAOD may be omitted from the linked CFA. Inan embodiment, for an employee with existing funds in a preexisting CFA,the funds will remain unchanged. But, funds within an existing CFAOD maybe adjusted according to the received update enrollment (or update)information. The amount enabled by the linked CFA upon successfullyprocessing enrollment and/or updates will be a sum of existing funds(which may have been rolled over from a previous plan year) stored in aCFA and a total of the future contributions in the plan year to be usedto fund a CFAOD. In an embodiment, an employer may have the capabilityto restrict/cap a maximum annual contribution amount and/or a maximumamount that may be borrowed or advanced from the CFAOD to the CFA in thelinked CFA, as described in FIG. 3 .

In step 708, status processing component 406 may be configured torequest bank accounts system 500 to set up a bank CFA corresponding to asub-account CFA of a linked CFA generated in step 706. The bank CFA maycorrespond to a traditional CFA. In an embodiment, if the linked CFAdoes not contain a CFA, then the bank CFA will not be set up and step708 may be omitted. In this embodiment, the linked CFA may contain oneor more CFAODs. In an embodiment where update information instead ofenrollment information is received at plan management system 400, statusprocessing component 406 may request bank accounts system 500 to updateinformation within a bank CFA. In an embodiment when step 708 is notomitted, status update processing component 506 in bank accounts system500 may process the received request, as described in FIG. 5 .

In step 710, status update processing component 506 may be configured tosend a result of processing the request. The result may confirm whetherthe bank CFA was successfully generated (or updated) or errors that wereencountered during account generation. In an embodiment, the result mayalso include a bank account number when generated by bank accountssystem 500. In an embodiment, if step 708 was omitted, then step 710 mayalso be omitted.

In step 712, upon successfully creating a bank CFA, status updateprocessing component 506 may send a card activation request to cardaccounts system 600. In an embodiment, the card activation request mayinclude a card account generated by plan management system 400 to beassociated with a card account created at card accounts system 600.

In step 714, status update processing component 606 of card accountssystem 600 may set up or update the card account and send acorresponding result of the activation request to plan management system400, as described in FIG. 6 .

In step 716, plan management system 400 may send a planned contributionfile upon receiving confirmation that both a bank CFA and the cardassociated with one or more linked CFAs have been successfully generatedfor an employee. The planned contribution file may include a number ofpay periods in a plan year and a contribution amount (or proportion ofincome) to be taken from an employee's paycheck for each pay period tofund a linked CFA. In an embodiment, a total of all future contributionsin the plan year may be included in the planned contribution file.Status update processing component 606 in card accounts system 600 mayreceive the planned contribution file and update funds within a cardCFAOD of a linked CFA to reconcile a card CFAOD with a CFAOD stored atplan management system 400. By reconciling the funds between the cardand the plan manager, the funds within the CFAOD at the card may beinitialized with an amount specified by the employer benefits plan.

In step 718, status update processing component 606 may sendreconciliation results back to plan management system 400.

In step 720, status processing component 406 may send a resultconfirming that the employee has been successfully enrolled into alinked CFA if the results from steps 710 and 718 do not indicate anyerrors. Otherwise, the confirmation result may include possible errorsencountered while trying to enroll the employee.

FIG. 8 illustrates a contribution process 800 for reconciling CFAsacross multiple systems in order to apply an employee contribution tohis linked CFA, enabling accelerated access to funds in CFAs, accordingto an example embodiment. The multiple systems may include employeraccount system 300, plan management system 400, bank accounts system500, and card accounts system 600 as described in FIGS. 3-6 ,respectively. Process 800 may be performed by processing logic that mayinclude hardware (e.g., circuitry, dedicated logic, programmable logic,microcode, etc.), software (e.g., instructions run on a processingdevice), or a combination thereof. In an embodiment, some steps in FIG.8 may not need to be performed in the exact order shown as one skilledin the arts would understand. For example, depending on the processingtimes of bank accounts system 500 and card accounts system 600, step 818may be performed before step 816.

In step 802, contribution processing component 308 of employer accountssystem 300 may send a contribution file to plan management system 400,as described in FIG. 3 . The contribution file may contain pledgedcontribution amounts of employees' corresponding paychecks that may beused to fund linked CFAs in the next pay period according to employees'elected employer benefit plans. The contribution file may be sentperiodically, for example, before the beginning of a next pay period.Upon receipt of the contribution file, contribution processing component408 may resolve the pledged contribution amounts and generate acontributions funding request (CFR). The CFR indicates a proportion ofthe contribution amounts in the contribution file sent in step 802 thathave been verified by plan management system 400 that should be sent byemployer accounts system 300 to plan management system 400. Acontribution amount for an employee may not be verified if, for example,the employee's linked CFA has been suspended or terminated.

In step 804, contribution processing component 408 may be configured tosend the CFR to employer accounts system 300.

In step 806, contribution processing component 308 may settle thereceived CFR and send the pledged contribution amounts specified in theCFR to plan management system 400. In an embodiment, the pledgedcontribution amounts may be sent via respective contributiontransactions. In an embodiment, to settle a contribution amount for oneemployee, the employee's elected contribution may be deducted from thepaycheck corresponding to a next pay period. Then, the deducted amountmay be transmitted to plan management system 400.

In step 810, contribution processing component 408 may initiate acontribution reconciliation process 808 by reconciling the linked CFA atthe plan management system 400. To reconcile a linked CFA account storedin linked CFA table 426, contribution processing component 408 may usethe received contribution amount to pay back as much of the amountborrowed 440 in the CFAOD as possible, effectively minimizing the amountborrowed 440. When the amount borrowed 440 is zeroed and a portion ofthe contribution amount remains, the remaining contribution amount maybe deducted from balance 438 of the CFAOD and contributed, effectivelytransferred, to the balance 432 of the CFA. Further details of thecontribution reconciliation process 808 are discussed in FIG. 12 .

In contrast to traditional procedures for adding a contribution to a CFAor even a linked CFA, contribution processing component 408 may beconfigured to delay contribution reconciliation of sub-accounts withinthe linked CFA until the CFR is settled and plan management system 400receives the employee's pledged contribution amount in step 806. Becausean employee enrolled in a linked CFA maintains access to both a CFAcontaining real funds and a CFAOD containing funds that are expected tobe contributed, no benefit is provided by updating a CFA or a CFAOD assoon as possible. Therefore, reconciliation may be delayed until enoughinformation is received to reconcile both the CFA and CFAOD at the sametime. This is an important advantage over traditional procedures, as itensures that the employee always has the full amount of their CFA andthe linked CFAOD available to them at all times—no reduction in totalfunds available to the employee due to processing lag times occurs. Uponreconciliation at the plan manager, an amount of funds specified by thecontribution amount may be added to the CFA and the same amount may bededucted from the CFAOD. The contribution amount is effectivelytransferred from the CFAOD to the CFA and a total of funds within thelinked CFA remains the same.

Upon resolving the contribution of at least the CFAOD, contributionprocessing component 408 may be configured to generate one or more banktransactions to be associated with the contribution transaction. The oneor more bank transactions may be stored in bank TXN log 424. In anembodiment, a possible bank transaction may be to contribute a portionof the received pledged contribution amount to a bank CFA such that abalance 514 of the bank CFA matches a resolved balance 432 of thecorresponding CFA in the management database 418.

In step 812, contribution processing component 408 may be configured tosend the generated bank transaction.

Upon resolving the contribution of at least the CFAOD, contributionprocessing component 408 may be configured to generate one or more cardtransactions to be associated with the contribution transaction. The oneor more card transactions may be stored in card TXN log 422. In anembodiment, a first card transaction may be to deduct a portion of thebalance 628 in a card CFAOD such that balance 628 matches a resolvedbalance 438 of the corresponding CFAOD at the provider. The secondtransaction, sent with the first transaction, may be to contribute anamount to balance 622A of a card CFA such that balance 628 matches aresolved balance 432 of the corresponding CFA in the management database418. Similar to reconciliation at plan management system 400, by addingthe contribution amount to balance 622A of the card CFA and deductingthe same amount from balance 628 of the CFAOD at the same time, thetotal amount of funds within the linked CFA at the card remainsunchanged before and after the contribution reconciliation process.Therefore, an employee using the card is not affected by the time ittakes to process the effective transferring of funds from the CFAOD tothe CFA.

In step 814, contribution processing component 408 may be configured tosend, in concurrence with performing step 812, the generated one or morecard transactions. By concurrently sending transactions to be applied atthe bank and the card vendor, latencies between sending the transactionsand receiving transaction results may be minimized. In traditionalprocesses, bank transactions associated with real funds in CFAs may needto be processed before increasing real funds in CFAs at the card. But,with a linked CFA comprising a CFA and a CFAOD operating according toembodiments of the present invention, card transactions may be sentbefore or in concurrence with sending bank transactions. This ensuresthat the employee always has the full amount of their CFA and the linkedCFAOD available to them at all times, rather than having the totalbalance of the two drop because of latency between the reduction ofavailable funds in the CFAOD record on the card due to the loggedcontribution, and the increase in available funds in the CFA record onthe card due to bank processing delays.

In step 816, TXN manager 604 at card server 602 may settle and apply thereceived one or more card transactions if no rules or restrictions of anemployer benefit plan are violated. Then, TXN manager 604 may send aresult of the settlement to plan management system 400. The result mayindicate errors if any were encountered.

Likewise in step 818, TXN manager 504 at bank server 502 may settle andapply the received one or more bank transactions if no rules orrestrictions of an employer benefit plan are violated. Then, TXN manager504 may send a result of the settlement to plan management system 400.The result may indicate errors if any were encountered.

Upon receiving settlement results from step 816 and step 818,contribution processing component 408 may initiate an errorreconciliation process to update the linked CFA in management database418 if any errors were encountered. One or more subsequent cardtransactions may be generated and sent to card accounts system 600 toreconcile updated balances at the provider with balances of the linkedCFA at the card. Due to the incorporation of a CFAOD in the linked CFA,even when an error is encountered, a portion of the funds in the cardCFA may be effectively transferred back to the CFAOD, but the totalfunds of the CFA and the CFAOD remains the same. An employee using acard linked to a linked CFA retains access to the total funds, which isnot affected by errors encountered during contribution reconciliation.

In step 820, if any portion of the pledged contribution amount was usedto pay off an amount borrowed 440 in step 810, invoice processingcomponent 412 may be configured to add a payback record to an EWFR, asdiscussed in FIG. 4 .

FIG. 9 illustrates a claims process 900 for reconciling CFAs acrossmultiple systems in order to apply an employee's claim via employee UIportal 202 to his linked CFA, enabling accelerated access to funds inCFAs, according to an example embodiment. The multiple systems mayinclude employee UI portal 202, employer account system 300, planmanagement system 400, bank accounts system 500, and card accountssystem 600 as described in FIGS. 2-6 , respectively. Process 900 may beperformed by processing logic that may include hardware (e.g.,circuitry, dedicated logic, programmable logic, microcode, etc.),software (e.g., instructions run on a processing device), or acombination thereof. In an embodiment, some steps in FIG. 9 may not needto be performed in the exact order shown as one skilled in the artswould understand. For example, depending on the processing times of bankaccounts system 500 and card accounts system 600, step 914 may beperformed and completed before step 912.

In step 902, claims generation component 206 in employee UI portal 202may send a claims request for an employee to plan management system 400.The claims request for the employee may be inputted into employee UIportal 202 by the employee via employee computer 104. In an embodiment,the claims request may be sent as one or more claims transactions. Asdescribed in FIG. 2 , a claims request may contain a claim amount, aservice type, a date of the service, and/or a servicing entity providingthe service for an employee. The claims request may be sent to planmanagement system 400 on a periodic basis or when prompted by an abenefits plan administrator.

In step 906, claims processing component 410 may initiate a claimsreconciliation process 904 by reconciling the linked CFA at the planmanagement system 400. To reconcile a linked CFA account stored inlinked CFA table 426, claims processing component 410 may use the fundswithin the linked CFA as specified by priorities stored in card accountssystem 600 for the employee, to determine whether the entire claimamount may be paid or reimbursed. The priorities may indicate not onlywhich sub-accounts are available to pay the claim, but also which orderto draw the funds from the eligible sub-accounts. If a total of theavailable funds within the linked CFA are sufficient, funds from balance432 of a CFA may be used before drawing funds from balance 438 of aCFAOD within the linked CFA. In an embodiment, if funds within the CFAare insufficient, an amount of funds may be deducted from balance 438 ofthe CFAOD and contributed, effectively transferred, to the balance 432of the CFA. The deducted amount is representative of an amount borrowedfrom the CFAOD and added to amount borrowed 440. Further details of theclaims reconciliation process 904 are discussed in FIG. 13 .

In step 908, claims processing component 410 may be configured to sendone or more bank transactions. Claims processing component 410 may beconfigured to generate the one or more bank transactions to beassociated with the received claims transaction upon resolving theclaims request at the plan management system 400. The one or more banktransactions may be stored in bank TXN log 424. In an embodiment, apossible bank transaction may be to contribute the amount deducted fromthe CFAOD at plan provider system 400 to a bank CFA such that a balance514 of the bank CFA matches a resolved balance 432 of the correspondingCFA in the management database 418. Another possible bank transactionmay be to deduct the claims amount from the bank CFA to service theclaims request.

In step 910, claims processing component 410 may be configured to send,in concurrence with performing step 908, one or more card transactions.Claims processing component 410 may be configured to generate the one ormore card transactions to be associated with the received claimstransaction upon resolving the claims request at the plan managementsystem 400 in step 906. The one or more card transactions may be storedin card TXN log 422. In an embodiment, a first card transaction may beto deduct a portion of the balance 628 in a card CFAOD such that balance628 matches a resolved balance 438 of the corresponding CFAOD at theprovider. A second transaction may be to add an amount to balance 622Aof a card CFA such that balance 628 matches a resolved balance 432 ofthe corresponding CFA in the management database 418. A thirdtransaction may be to deduct the claim amount from the bank CFA. In anembodiment, one or more of the first, second, and third transactions maybe combined such that after processing the transaction(s), the balancesof the linked CFA at the card vendor match the balances of the linkedCFA at the provider.

By concurrently sending transactions to be applied at the bank and thecard vendor, latencies between sending the transactions and receivingtransaction results may be minimized. This is an advantage overtraditional processes. In traditional processes, bank transactionsassociated with real funds in CFAs may need to be processed beforeincreasing real funds in CFAs at the card. But, with a linked CFAcomprising a CFA and a CFAOD, card transactions may be sent before or inconcurrence with sending bank transactions such that the employee alwayshas the maximum amount of funds available at all times.

In step 912, TXN manager 504 at bank server 502 may settle and apply thereceived one or more bank transactions if no rules or restrictions of anemployer benefit plan are violated. Then, TXN manager 504 may send aresult of the settlement to plan management system 400. The result mayindicate errors if any were encountered.

Likewise in step 914, TXN manager 604 at card server 602 may settle andapply the received one or more card transactions if no rules orrestrictions of an employer benefit plan are violated. Then, TXN manager604 may send a result of the settlement to plan management system 400.The result may indicate errors if any were encountered.

In step 916, upon receiving settlement results from step 912 and step916, claims processing component 410 may process the received settlementresults. In an embodiment, claims processing component 410 may initiatean error reconciliation process to update the linked CFA in managementdatabase 418 if any errors were encountered. One or more subsequent cardtransactions may be generated and sent to card accounts system 600 toreconcile updated balances at the provider with balances of the linkedCFA at the card. Due to the incorporation of a CFAOD in the linked CFA,even when an error is encountered, a portion of the funds in the cardCFA may be effectively transferred back to the CFAOD, but the totalfunds of the CFA and the CFAOD remains the same. An employee using acard linked to a linked CFA retains access to the total funds, which isnot affected by errors encountered during contribution reconciliation.

In an embodiment, as part of step 916, claims processing component 410may add a billing record to an EWFR if an amount was deducted,effectively borrowed, from balance 438 of the CFAOD of a linked CFA toservice a claim, as discussed in FIG. 4 . In an embodiment, only claimsthat borrowed from balance 438 of the CFAOD may be added as a billingrecord to the EWFR. In an embodiment, claims processing component 410may add the billing record to the EWFR at the end of step 906. But ifany errors were encountered, the added billing record may need to beadjusted in step 916.

In step 918, the EWFR containing payback and billing records may be sentby invoice processing component 412 in plan management system 400 toemployer accounts system 300.

In step 920, invoice reporting component 310 in employer accounts system300 may process the received EWFR and settle the amounts as specified inthe EWFR. Accordingly, a result of the settlement including paymentamounts may be sent to plan management system 400.

FIG. 10 illustrates a claims process 1000 for reconciling CFAs acrossmultiple systems in order to apply an employee's claim, originating froma card, to his linked CFA enabling accelerated access to funds in CFAODsof linked CFAs, according to an example embodiment. The multiple systemsmay include employer account system 300, plan management system 400,bank accounts system 500, and card accounts system 600 as described inFIGS. 3-6 , respectively. Process 1000 corresponds closely with process900, but one or more steps of process 900 may be omitted because theclaim request is originated by a card maintained by a card vendor incard accounts system 600. Process 1000 may be performed by processinglogic that may include hardware (e.g., circuitry, dedicated logic,programmable logic, microcode, etc.), software (e.g., instructions runon a processing device), or a combination thereof. In an embodiment,some steps in FIG. 10 may not need to be performed in the exact ordershown as one skilled in the arts would understand.

When an employee pays for a service using his card associated with alinked CFA, TXN manager 604 in card accounts system 600 may generate aclaims transaction representative of the attempted card payment for theservice. The claims transaction may be viewed as a claims request madeby the employee. The card payment may be initiated when, for example,the employee swipes his card to pay for a service.

In step 1002, TXN manager 604 may send a claims request in the form ofthe generated claims transaction to plan management system 400. In anembodiment, the claims request may be sent as one or more claimstransactions. As described in FIG. 6 , a claims request generated at thecard may contain a claim amount, a date of service, a service type,and/or a servicing entity. The claims request may be sent to planmanagement system 400 at the point-of-sale when the card is swiped topay for a service. In an embodiment, the claims request received at planprovider system 400 may include a transaction indicating a total claimsamount to be drawn from the CFA regardless of whether the total claimsamount exceeds the funds within the CFA.

In step 1006, claims processing component 410 may initiate a claimsreconciliation process 1004 by reconciling the linked CFA at the planmanagement system 400. Similar to the processes described in step 906 ofFIG. 9 and further discussed in FIG. 13 , to reconcile a linked CFAaccount stored in linked CFA table 426, claims processing component 410may use the funds within the linked CFA as specified by a selected MPtable to determine whether the entire claim amount may be serviced ordenied. The balances of sub-accounts within the linked CFA are resolvedaccordingly.

In step 1008, claims processing component 410 may similarly generate oneor more bank transactions to associate with the claims transaction andsend the generated bank transaction(s), as described in step 908 of FIG.9 .

In step 1009, claims processing component 410 may generate one or morecard transactions to transfer any amount deducted/borrowed from theCFAOD to fund the CFA to cover the remaining balance, as described instep 910 of FIG. 9 . In an embodiment, if the CFAOD funds at the card incard accounts system 600 were not borrowed to service a cardtransaction, then step 1009 and corresponding step 1011 may not need tobe performed.

In step 1010, TXN manager 504 at bank server 502 may settle and applythe received one or more bank transactions if no rules or restrictionsof an employer benefit plan are violated. Then, TXN manager 504 may senda result of the settlement to plan management system 400. The result mayindicate errors if any were encountered.

Likewise in step 1011, TXN manager 604 at card server 602 may settle andapply the received one or more card transactions if no rules orrestrictions of an employer benefit plan are violated. Then, TXN manager604 may send a result of the settlement to plan management system 400.The result may indicate errors if any were encountered.

In step 1012, upon receiving the settlement result from step 1010 andsettlement result from step 1011 if step 1009 was initiated, claimsprocessing component 410 may process the received settlement result.Because the claims request originated from card accounts system 600, thebalances within the linked CFA of the card at card accounts system 600may be presumed to be up-to-date and no further card transactions mayneed to be transmitted between plan management system 400 and cardaccounts system 600.

In an embodiment, claims processing component 410 may initiate an errorreconciliation process to update the linked CFA in management database418 if any errors were encountered. As part of error reconciliation, oneor more subsequent card transactions may be generated and sent to cardaccounts system 600 to reconcile updated balances at the provider withbalances of the linked CFA at the card. Due to the incorporation of aCFAOD in the linked CFA, even when an error is encountered, a portion ofthe funds in the card CFA may be effectively transferred back to theCFAOD, but the total funds of the CFA and the CFAOD remains the same. Anemployee using a card linked to a linked CFA retains access to the totalfunds, which is not affected by errors encountered during contributionreconciliation.

In step 1014, the EWFR containing payback and billing records may besent by invoice processing component 412 in plan management system 400to employer accounts system.

In step 1016, invoice reporting component 310 in employer accountssystem 300 may process the received EWFR and settle the amounts asspecified in the EWFR. Accordingly, a result of the settlement includingpayment amounts may be sent to plan management system 400.

FIG. 11 illustrates a method 1100 for reconciling acceleratedcontribution funded accounts between employer accounts system 300 andplan management system 400 when an employee leaves his employer. Method1100 may be performed by processing logic that may include hardware(e.g., circuitry, dedicated logic, programmable logic, microcode, etc.),software (e.g., instructions run on a processing device), or acombination thereof. In an embodiment, some steps in FIG. 11 may notneed to be performed in the exact order shown as one skilled in the artswould understand.

In step 1102, status update processing component 306 may send atermination request to plan management system 400 indicating an employeeis to be terminated from one or more linked CFAs.

In step 1104, status update processing component 406 in plan managementsystem 400 may reconcile a linked CFA of the terminated employee. In anembodiment, status 430 of a CFA may be set to CLOSED and status 436 of aCFAOD may be set to IN-COLLECTION. If the amount borrowed 440 in theCFAOD is zero, status update processing component 406 may instead set aCFAOD of the linked CFA to CLOSED. Relatedly (not shown in FIG. 11 ),status update processing component 406 may send associated transactionsto the bank and the card vendor via TXN manager 414 to close relatedCFAs and CFAODs. Alternatively, if the employee is to maintain the CFA,the CFA may remain open with any existing funds available to theemployee while status 436 of the CFAOD may be set to CLOSED orIN-COLLECTION.

In step 1106, invoice processing component 412 may send paybackinformation via a payback report to employer accounts system 300. Thepayback information may indicate whether the employee has a remainingbalance in the amount borrowed 440 of any CFAODs and how much theemployee has borrowed from the CFAODs.

In step 1108, employer accounts system 300 may record the paybackinformation and an employer may retrieve the specified funds from theemployee.

In step 1110, employer accounts system 300 may periodically send resultsof a progress of the payback/collections process to plan managementsystem 400. In an embodiment, employer accounts system 300 may sendresults whenever the employee pays back a portion of the specifiedborrowed amount.

In step 1112, plan management system 400 may process the receivedpayback results. For example, the amount borrowed 440 of a CFAOD may bereduced. In the exemplary embodiment of FIG. 11 , the collectionsprocess is performed by employer accounts system 300, and planmanagement system 400 only monitors a status of the collections. In anembodiment, the collections process of step 1108 may be performed byplan management system 400. Depending on the capabilities of employeraccounts system 300 and the needs of employers, plan management system400 may perform the collections process for one employer and only trackstatuses of the collection process for another employer.

In step 1114, plan management system 400 may send update reports onstatuses of CFAODs. These reports may be sent on a periodic basis or besent in response to received results of step 1110.

FIG. 12 illustrates a method 1200 for reconciling acceleratedcontribution funded accounts across multiple systems at a planmanagement system in order to process a contribution from an employer,according to an example embodiment. The multiple systems may includeemployer account system 300, plan management system 400, bank accountssystem 500, and card accounts system 600 as described in FIGS. 3-6 ,respectively. Method 1200 may correspond to the steps described anddetailed in reconciliation process 808 described in FIG. 8 . Method 1200may be performed by processing logic that may include hardware (e.g.,circuitry, dedicated logic, programmable logic, microcode, etc.),software (e.g., instructions run on a processing device), or acombination thereof. In an embodiment, some steps in FIG. 12 may notneed to be performed in the exact order shown as one skilled in the artswould understand.

In step 1202, contribution processing component 408 may receive apledged contribution amount for an employee's linked CFA stored inmanagement database 418.

In step 1204, contribution processing component 408 may determinewhether an amount borrowed 440 in CFAOD is non-zero. If the amountborrowed 440 exists, method 1200 proceeds to step 1214.

In step 1214, contribution processing component 408 may apply as much ofthe received contribution amount as possible to pay back and minimizethe amount borrowed 440.

In step 1216, invoice processing component 412 may add a payback recordto an EWFR. The payback record may contain an amount corresponding tothe portion of received contribution amount used to minimize the amountborrowed 440.

In step 1218, contribution processing component 408 may determinewhether any portion of the received contribution amount remains andneeds to be resolved. If a contribution amount remains, method 1200proceeds to step 1206.

Returning to step 1204, if the amount borrowed 440 is zero, method 1200proceeds to 1206. In step 1206, contribution processing component 408may transfer a remaining contribution amount from the CFAOD to the CFA.In practice, the remaining contribution amount may be deducted from theCFAOD and added to the CFA.

In step 1208, TXN manager 414 may generate bank transactions based onthe reconciliation of contributions performed within plan managementsystem 400 and send the bank transactions to bank accounts system 500 toreconcile CFAs stored in bank database 508.

In step 1210, TXN manager 414 may generate card transactions based onthe reconciliation of contributions performed within plan managementsystem 400 and concurrently send the card transactions to card accountssystem 600 to reconcile CFAs and CFAODs stored in card database 608.

In step 1212, contribution processing component 408 may receiveconfirmation results of the transactions sent in steps 1208 and 1210. Iferrors were encountered, an error reconciliation process as described inFIG. 8 may be initiated. Method 1200 ends in step 1220.

FIG. 13 illustrates a method 1300 for reconciling acceleratedcontribution funded accounts across multiple systems at a planmanagement system in order to process a claim, according to an exampleembodiment. The multiple systems may include employer account system300, plan management system 400, bank accounts system 500, and cardaccounts system 600 as described in FIGS. 3-6 , respectively. Method1300 may correspond to the steps described and detailed in claimsreconciliation processes 904 and 1004 described in FIGS. 9 and 10 ,respectively. Method 1300 may be performed by processing logic that mayinclude hardware (e.g., circuitry, dedicated logic, programmable logic,microcode, etc.), software (e.g., instructions run on a processingdevice), or a combination thereof. In an embodiment, steps in FIG. 13may not need to be performed in the exact order shown as one skilled inthe arts would understand.

In step 1302, claims processing component 410 may receive a claimsrequest. The claims request may include a service type, a date of theservice, the service provider, and a claim amount. The claims requestmay be received from employee UI portal 202, card accounts system 112,or another entity such as a benefits plan provider.

In step 1304, claims processing component 410 may retrieve informationon eligible sub-accounts within the employee's linked CFA to pay for theservice. In an embodiment where the claim is received from a cardvendor, the claims request may include a multi-purse (MP) indicatorwhich enables claims processing component 410 to select an appropriateMP table, such as MP table 612A that is correspondingly stored inmanagement database 418. By using the appropriate MP table, claimsprocessing component 410 may determine which sub-accounts and in whichorder to draw funds from the sub-accounts to service the claim. In anembodiment, if the claim is not received from a card vendor, claimsprocessing component 410 may retrieve priorities stored withinmanagement database 418 to determine which sub-accounts and in whichorder to draw funds from the sub-accounts to service the claim. Theclaim may be received from, for example, a benefits plan provider or anemployee manually entering the claim into employee UI portal 202.

In step 1306, claims processing component 410 may add the fundsavailable from an ordered set of sub-accounts (e.g., enabled in MP table612A for a card transaction) to pay for a claim according to whether theservice type of the claim is allowed in the employer benefit plan. Forexample, funds from CFA 618A may be used before CFAOD 624 and CFA 618B.In an embodiment, CFAs within a linked CFA may always be prioritizedover CFAODs within the same linked CFA.

In step 1308, if the funds within the sub-accounts of the linked CFA areinsufficient, claims processing component 410 may deny the claim andsend a notification to the originator of the claims request.

In step 1310, claims processing component 410 may determine whetherenough funds represented by balance 432 within the CFA is sufficient toservice the claim amount.

In step 1314, if funds within the CFA is not sufficient, claimsprocessing component 410 may transfer funds from the CFAOD to the CFA.The transferring of funds may include deducting a portion of balance 438in the CFAOD and adding the deducted portion to balance 432 of the CFAsuch that balance 432 of the CFA is greater or equal to the claimamount. Additionally, claims processing component 410 may add thededucted portion to an amount borrowed 440 of the CFAOD because anemployee is effectively borrowing against his future contributionsstored in the CFAOD.

In step 1316, invoice processing component 412 may add a billing recordto the EWFR. The billing record may bill the amount deducted from theCFAOD to the employer.

In step 1312, claims processing component 410 may deduct the claimamount from the CFA. Step 1314 may guarantee that if the total funds inthe linked CFA are sufficient, at least the claim amount can be deductedfrom the CFA.

In step 1318, TXN manager 414 may send one or more bank transactionsgenerated to service the clam request and reconcile the bank CFA withthe CFA stored in management database 418.

In step 1320, claims processing component 410 may determine whether theclaims request was received from a card vendor. If card accounts system112 associated with a card vendor generated the claims request, then thesub-accounts within the linked CFA will have already been updated andmethod 1300 ends in step 1324. In an embodiment, if the card transactionindicates an amount to be withdrawn from a card CFA regardless ofwhether funds from the card CFAOD were used, then method 1300 mayinstead proceed to step 1322.

In step 1322, claims processing component 410 may send, in concurrencewith performing step 1318, one or more card transactions generated toreconcile the card CFAs and CFAODs with the CFAs and CFAODs stored inmanagement database 418. In an embodiment, if the claim was generated bycard accounts system 600 via a card swipe, concurrent updatetransactions may only be sent to the card if funds from card CFAODs wereborrowed to service the card transaction.

FIG. 14 illustrates a method 1400 for reconciling acceleratedcontribution funded accounts at a card account system, such as cardaccounts system 600, in order to process a payment transaction (i.e.card claims request) initiated when the card is used by the employee,according to an example embodiment. Method 1400 may correspond to step1002 described and detailed in FIG. 10 . Method 1400 may be performed byprocessing logic that may include hardware (e.g., circuitry, dedicatedlogic, programmable logic, microcode, etc.), software (e.g.,instructions run on a processing device), or a combination thereof. Inan embodiment, steps in FIG. 14 may not need to be performed in theexact order shown as one skilled in the arts would understand.

In step 1402, TXN manager 604 may receive a payment transaction when acard is used or swiped. The payment transaction or claim/payment requestmay be associated with a service type, service provider, and a claimamount.

In step 1404, card server 602 may retrieve a currently selected MP table612 associated with a linked CFA of the card account. For example, cardserver 602 may retrieve MP table 612A.

In step 1406, card server 602 may add the funds available from anordered set of sub-accounts enabled in the retrieved MP table 612A todetermine whether funds in the card account are sufficient to pay for aclaim according to whether the service type of the claim is allowed inthe employer benefit plan. For example, funds from CFA 618A may be usedbefore CFAOD 624 and CFA 618B.

In step 1408, the funds within the sub-accounts of the linked CFA werefound to be insufficient, so card server 602 may deny the claims requestand send a notification to the originator of the claims request. In anembodiment, when a card is swiped to pay for a particular service, thetransaction may be immediate denied.

In step 1410, card server 602 may determine whether the claim amountexceeds the funds represented by balance 622A within the CFA of thelinked CFA stored in the card. If the amount exceeds the funds availablein the CFA, method 1400 proceeds to step 1416.

In step 1416, all of the funds may be deducted from the CFA, renderingbalance 622A zero, to service the claim amount.

In step 1418, a portion of funds represented by balance 628 may bededucted from the CFAOD to pay off the remaining claim amount.

In step 1412, when the claim amount of the payment request does notexceed balance 622A of the CFA, the claim amount is deducted frombalance 622A of the CFA. In step 1414, TXN manager 604 may generate andsend card claim record to plan management system 400. The card claimrecord may include a card claim transaction specifying the amountdeducted from the CFA. If funds from the CFAOD were used, the card claimrecord may include another card claim transaction specifying the amountdeducted from the CFAOD.

FIG. 15 is an example computer system that may be used to implementaspects of the systems illustrated in FIGS. 1-6 , or which may bespecially programmed to implement aspects of the processes illustratedin FIGS. 7-14 . Computer system 1500 includes one or more processors(also called central processing units, or CPUs), such as a processor1504. Processor 1504 is connected to a communication infrastructure orbus 1506.

One or more processors 1504 may each be a graphics processing unit(GPU). In an embodiment, a GPU is a processor that is a specializedelectronic circuit designed to process mathematically intensiveapplications. The GPU may have a parallel structure that is efficientfor parallel processing of large blocks of data, such as mathematicallyintensive data common to computer graphics applications, images, videos,etc.

Computer system 1500 also includes user input/output device(s) 1503,such as monitors, keyboards, pointing devices, etc., that communicatewith communication infrastructure 15015 through user input/outputinterface(s) 1502.

Computer system 1500 also includes a main or primary memory 1508, suchas random access memory (RAM). Main memory 1508 may include one or morelevels of cache. Main memory 1508 has stored therein control logic(i.e., computer software) and/or data.

Computer system 1500 may also include one or more secondary storagedevices or memory 1510. Secondary memory 1510 may include, for example,a hard disk drive 1512 and/or a removable storage device or drive 1514.Removable storage drive 1514 may be a floppy disk drive, a magnetic tapedrive, a compact disk drive, an optical storage device, tape backupdevice, and/or any other storage device/drive. Removable storage drive1514 may interact with a removable storage unit 1518.

Removable storage unit 1518 includes a computer usable or readablestorage device having stored thereon computer software (control logic)and/or data. Removable storage unit 1518 may be a floppy disk, magnetictape, compact disk, DVD, optical storage disk, and/any other computerdata storage device. Removable storage drive 1514 reads from and/orwrites to removable storage unit 1518 in a well-known manner.

According to an example embodiment, secondary memory 1510 may includeother means, instrumentalities or other approaches for allowing computerprograms and/or other instructions and/or data to be accessed bycomputer system 1500. Such means, instrumentalities or other approachesmay include, for example, a removable storage unit 1522 and an interface1520. Examples of the removable storage unit 1522 and the interface 1520may include a program cartridge and cartridge interface (such as thatfound in video game devices), a removable memory chip (such as an EPROMor PROM) and associated socket, a memory stick and USB port, a memorycard and associated memory card slot, and/or any other removable storageunit and associated interface.

Computer system 1500 may further include a communication or networkinterface 1524. Communication interface 1524 enables computer system1500 to communicate and interact with any combination of remote devices,remote networks, remote entities, etc. (individually and collectivelyreferenced by reference number 1528). For example, communicationinterface 1524 may allow computer system 1500 to communicate with remotedevices 1528 over communications path 15215, which may be wired and/orwireless, and which may include any combination of LANs, WANs, theInternet, etc. Control logic and/or data may be transmitted to and fromcomputer system 1500 via communication path 15215.

In an embodiment, a tangible apparatus or article of manufacturecomprising a tangible computer useable or readable medium having controllogic (software) stored thereon is also referred to herein as a computerprogram product or program storage device. This includes, but is notlimited to, computer system 1500, main memory 1508, secondary memory1510, and removable storage units 1518 and 1522, as well as tangiblearticles of manufacture embodying any combination of the foregoing. Suchcontrol logic, when executed by one or more data processing devices(such as computer system 1500), causes such data processing devices tooperate as described herein.

Based on the teachings contained in this disclosure, it will be apparentto persons skilled in the relevant art(s) how to make and useembodiments of the present disclosure using data processing devices,computer systems and/or computer architectures other than that shown inFIG. 15 . In particular, embodiments may operate with software,hardware, and/or operating system implementations other than thosedescribed herein.

It is to be appreciated that the Detailed Description section, and notthe Summary and Abstract sections (if any), is intended to be used tointerpret the claims. The Summary and Abstract sections (if any) may setforth one or more but not all exemplary embodiments of the invention ascontemplated by the inventor(s), and thus, are not intended to limit theinvention or the appended claims in any way.

While the invention has been described herein with reference toexemplary embodiments for exemplary fields and applications, it shouldbe understood that the present disclosure is not limited thereto. Otherembodiments and modifications thereto are possible, and are within thescope and spirit of the present disclosure. For example, and withoutlimiting the generality of this paragraph, embodiments are not limitedto the software, hardware, firmware, and/or entities illustrated in thefigures and/or described herein. Further, embodiments (whether or notexplicitly described herein) have significant utility to fields andapplications beyond the examples described herein.

Embodiments have been described herein with the aid of functionalbuilding blocks illustrating the implementation of specified functionsand relationships thereof. The boundaries of these functional buildingblocks have been arbitrarily defined herein for the convenience of thedescription. Alternate boundaries may be defined as long as thespecified functions and relationships (or equivalents thereof) areappropriately performed. Also, alternative embodiments may performfunctional blocks, steps, operations, methods, etc. using orderingsdifferent than those described herein.

References herein to “one embodiment,” “an embodiment,” “an exampleembodiment,” or similar phrases, indicate that the embodiment describedmay include a particular feature, structure, or characteristic, butevery embodiment may not necessarily include the particular feature,structure, or characteristic. Moreover, such phrases are not necessarilyreferring to the same embodiment. Further, when a particular feature,structure, or characteristic is described in connection with anembodiment, it would be within the knowledge of persons skilled in therelevant art(s) to incorporate such feature, structure, orcharacteristic into other embodiments whether or not explicitlymentioned or described herein.

The breadth and scope of the present disclosure should not be limited byany of the above-described exemplary embodiments, but should be definedonly in accordance with the following claims and their equivalents.

1.-20. (canceled)
 21. A computer-implemented method comprising:receiving, by one or more processors and from a card accounts system, aclaims request comprising a claim amount, a service type, and amulti-purse (“MP”) indicator; selecting, by the one or more processorsand using the MP indicator, an MP table corresponding to a userassociated with the claims request, wherein: (i) the MP table is storedin (a) a management database and (b) the card accounts system, (ii) theMP table specifies (a) one or more priorities and (b) one or morequalified service types for each of one or more sub-accounts for theuser, identifying, by the one or more processors and using the MP table,an ordered set of sub-accounts for the claims request, wherein theordered set of sub-accounts is based at least in part on (a) acomparison between the service type and the one or more qualifiedservice types for each of one or more sub-accounts for the user and (b)the one or more priorities for each of one or more sub-accounts for theuser; responsive to the claim amount exceeding a contribution fundedaccount (CFA) balance, initiating, by the one or more processors inaccordance with the ordered set of sub-accounts, a transfer of fundsfrom a contribution funded account on demand (CFAOD) to a CFA by: (i)deducting a portion of the CFAOD balance, (ii) adding the portion of theCFAOD balance to the CFA, and (iii) adding the portion of the CFAODbalance to an amount borrowed; and concurrently with one or more banktransactions, providing, by the one or more processors, one or moreupdate transactions to the card accounts system to reconcile a card CFAand a card CFAOD with the CFA and the CFAOD.
 22. Thecomputer-implemented method of claim 21, further comprising: initiating,in accordance with the ordered set of sub-accounts, one or more banktransactions to a bank processor to service the claims request andreconcile a bank CFA with the CFA.
 23. The computer-implemented methodof claim 21, wherein the one or more sub-accounts for the user comprisea plurality of CFA and a plurality of CFAOD and identifying the orderedset of sub-accounts comprises identifying the CFA from the plurality ofCFA and the CFAOD from the plurality of CFAOD based on the service type.24. The computer-implemented method of claim 21, wherein the user isassociated with a plurality of MP indicators and the MP indicator isbased on one or more statuses of the one or more sub-accounts for theuser.
 25. The computer-implemented method of claim 21, wherein the oneor more statuses identify whether one or more of the one or moresub-accounts comprise invested funds and the MP indicator is used toselect the MP table comprising the ordered set of enabled accounts thatexcludes a respective card CFAOD linked to the invested funds.
 26. Thecomputer-implemented method of claim 21, wherein the MP table identifiesthe CFA from a CFA table and the CFAOD from a CFAOD table.
 27. Thecomputer-implemented method of claim 26, wherein the CFA table is storedin (a) the management database and (b) the card accounts system.
 28. Thecomputer-implemented method of claim 26, wherein the CFAOD table isstored in (a) the management database and (b) the card accounts system.29. A computing system comprising memory and one or more processorscommunicatively coupled to the memory, the one or more processorsconfigured to: receive, from a card accounts system, a claims requestcomprising a claim amount, a service type, and a multi-purse (“MP”)indicator; select, using the MP indicator, an MP table corresponding toa user associated with the claims request, wherein: (i) the MP table isstored in (a) a management database and (b) the card accounts system,(ii) the MP table specifies (a) one or more priorities and (b) one ormore qualified service types for each of one or more sub-accounts forthe user, identify, using the MP table, an ordered set of sub-accountsfor the claims request, wherein the ordered set of sub-accounts is basedat least in part on (a) a comparison between the service type and theone or more qualified service types for each of one or more sub-accountsfor the user and (b) the one or more priorities for each of one or moresub-accounts for the user; responsive to the claim amount exceeding acontribution funded account (CFA) balance, initiate, in accordance withthe ordered set of sub-accounts, a transfer of funds from a contributionfunded account on demand (CFAOD) to a CFA by: (i) deducting a portion ofthe CFAOD balance, (ii) adding the portion of the CFAOD balance to theCFA, and (iii) adding the portion of the CFAOD balance to the amountborrowed; and concurrently with one or more bank transactions, provideone or more update transactions to the card accounts system to reconcilea card CFA and a card CFAOD with the CFA and the CFAOD.
 30. Thecomputing system of claim 29, wherein the one or more processors arefurther configured to: initiate, in accordance with the ordered set ofsub-accounts, one or more bank transactions to a bank processor toservice the claims request and reconcile a bank CFA with the CFA. 31.The computing system of claim 29, wherein the one or more sub-accountsfor the user comprise a plurality of CFA and a plurality of CFAOD andidentifying the ordered set of sub-accounts comprises identifying theCFA from the plurality of CFA and the CFAOD from the plurality of CFAODbased on the service type.
 32. The computing system of claim 29, whereinthe user is associated with a plurality of MP indicators and the MPindicator is based on one or more statuses of the one or moresub-accounts for the user.
 33. The computing system of claim 29, whereinthe one or more statuses identify whether one or more of the one or moresub-accounts comprise invested funds and the MP indicator is used toselect the MP table comprising the ordered set of enabled accounts thatexcludes a respective card CFAOD linked to the invested funds.
 34. Thecomputing system of claim 29, wherein the MP table identifies the CFAfrom a CFA table and the CFAOD from a CFAOD table.
 35. The computingsystem of claim 34, wherein the CFA table is stored in (a) themanagement database and (b) the card accounts system.
 36. The computingsystem of claim 34, wherein the CFAOD table is stored in (a) themanagement database and (b) the card accounts system.
 37. One or morenon-transitory computer-readable storage media including instructionsthat, when executed by one or more processors, cause the one or moreprocessors to: receive, from a card accounts system, a claims requestcomprising a claim amount, a service type, and a multi-purse (“MP”)indicator; select, using the MP indicator, an MP table corresponding toa user associated with the claims request, wherein: (i) the MP table isstored in (a) a management database and (b) the card accounts system,(ii) the MP table specifies (a) one or more priorities and (b) one ormore qualified service types for each of one or more sub-accounts forthe user, identify, using the MP table, an ordered set of sub-accountsfor the claims request, wherein the ordered set of sub-accounts is basedat least in part on (a) a comparison between the service type and theone or more qualified service types for each of one or more sub-accountsfor the user and (b) the one or more priorities for each of one or moresub-accounts for the user; responsive to the claim amount exceeding acontribution funded account (CFA) balance, initiate, in accordance withthe ordered set of sub-accounts, a transfer of funds from a contributionfunded account on demand (CFAOD) to a CFA by: (i) deducting a portion ofthe CFAOD balance, (ii) adding the portion of the CFAOD balance to theCFA, and (iii) adding the portion of the CFAOD balance to the amountborrowed; and concurrently with one or more bank transactions, provideone or more update transactions to the card accounts system to reconcilea card CFA and a card CFAOD with the CFA and the CFAOD.
 38. The one ormore non-transitory computer-readable storage media of claim 29, whereinthe user is associated with a plurality of MP indicators and the MPindicator is based on one or more statuses of the one or moresub-accounts for the user.
 39. The one or more non-transitorycomputer-readable storage media of claim 29, wherein the one or morestatuses identify whether one or more of the one or more sub-accountscomprise invested funds and the MP indicator is used to select the MPtable comprising the ordered set of enabled accounts that excludes arespective card CFAOD linked to the invested funds.
 40. The one or morenon-transitory computer-readable storage media of claim 29, wherein theone or more statuses identify whether one or more of the one or moresub-accounts comprise invested funds and the MP indicator is used toselect the MP table comprising the ordered set of enabled accounts thatexcludes a respective card CFAOD linked to the invested funds.